隨著容器虛擬化技術的盛行，把一個 Application 封裝進容器內，特過容器的快速啟動、刪除的特性，讓每一次 Application 使用都是新的一個 Application，進而減少了系統長期運行的監控與恢復
基本上這句話就是使用容器化技術的原因。
Container 也具有 瞬間啟動、完成任務後自動銷毀、隨時都可以被關閉 / 取代 的特性。
容器化技術也是 Serverless 架構的精隨，你不再需要維護伺服器底層，把整個應用程式關注在資料的輸入以及輸出，程式碼的撰寫在於快速、精準的處理資料，減少底層硬體的影響。
Lambda 是一個水平擴充的服務。在 Day 10 - Auto Scaling 自動擴展 這個篇章有提到過。
它會增加服務器的數量來擴展系統效能。本身也就支援高併發的架構，可瞬間擴張到千個。
但是併發的數量有其上限，但是可以透過設定做調整
同時也具備著 Container 的特性，可以快速地啟用、隨後刪除，並且是隨開隨用，根據流量以及存取次數去計算費用，畢竟不是所有的服務都 24 小時有流量，流量也不是這麼高的情況下， Lambda 真的是一個不錯的選擇！
AWS Lambda 有提供每個月 100 萬次的啟動，一個 Function 最大能執行 15 分鐘。
一句話說明三者的關係:
Trigger 會將收到的 Event 交給 Function 去做處理
Event 的來源有很多種，可能來自於 S3，也可能來自於 API Gateway，基本上 AWS 的服務都有可能有支援 Lambda，這些從各個地方啟動 Lambda 的來源，就是 Event。
Trigger 就是負責接收各地來源的 Event，收到後會把對應的 Function 給啟動起來。
Function 就是實際執行程式碼的地方。要注意若需要跟其他 AWS 服務進行溝痛，需要為其配置一個 IAM Role。
Runtime (運行環境) ，是運行程式碼的環境。
Runtime 是運行 Function 所需的程式語言所建立的基礎環境。
Layer (中繼的套件) ，當 Lambda Function 執行時，需要一些額外套件與環境，可考慮使用 Layer。
Layer 將會附加進 Runtime 裡面，不需要每次都將使用到的函式庫也納入部屬對象裡面。Layer 製作完成後會壓縮成 zip 檔，內容包含了 函式庫、自訂的執行時間、其它的依賴項目。
這邊可以參考 AWS Blog 官網畫的圖:
可以說是 Lambda Function 的版本控制，是依附在 Lambda Function 上面，一個 Function 可以有很多個版號來進行迭代。
當發佈新版本，內容會包含以下:
可針對 Lambda Function 建立一個或多個別名。
前面提到的 Function Version，單純的版號沒有任何意義，這時候就需要 Alias 來賦予 Version 意義了。類似於 Git 的 Tag 功能。
例如:
我們有 V1, V2, V3 三個 Version。
可以指定 Dev 這個 Alias 指到 V3 這個版本; UAT 這個 Alias 指到 V2 這個版本; PROD 這個 Alias 指到 V1 這個版本。
之後也可以使用 ARN 來存取 Lambda Function 特定的 Version 來進行各個環境的佈署了。
在 Serverless 架構中，AWS Lambda 是一個重要的服務，實際執行業務處理的重要任務。也因為其特性在於有需求才開啟，所以沒有使用自然也就會關閉。
當需要執行的時候，就會有啟動時間，這個 啟動時間也就是 Warm Up 的時間 。
Warm Up 的時間有長有短，主要用來建立 Runtime 環境，當使用者來存取你的服務的時候，這個 額外的 Warm Up 的時間就有可能會導致使用者體驗不佳。
我參考其他邦友提出來的解決方法:
Warm-up 的機制就是透過建立一個 Lambda 來打一個 flag 到其他 Lambda 來他們別進入睡眠模式
運算時間越久，費用就越高。
iThome鐵人賽
看影片追技術